home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Internet Tools 1995 April / Internet Tools.iso / infoserv / www / cern / doc / www-talk.archive.Z / www-talk.archive / text0418.txt < prev    next >
Encoding:
Text File  |  1992-11-30  |  4.5 KB  |  121 lines
  1.  
  2.  
  3. >  Date: Wed, 25 Nov 92 12:41:49 est
  4. >  From: jim@wilbur.njit.edu (Jim Whitescarver)
  5.  
  6. >  We are not stuck on the <PRE> tag, only the functionality.  If <p> at
  7. >  the end gave us single spaced output, that would be acceptable though a
  8. >  bit more work.  I've been unable to duplicate the effect using existing
  9. >  tags.  Whatever name, (I'd prefer <PREFORMATTED>),
  10.  
  11. PREFORMATTED is too long for default SGML element length.
  12. I feel FIXED is more descriptive of what the tag means -- in that the character  
  13. spacing is fixed.  I feel the tag should describe the interpretation to be but  
  14. onto the data, not just its origin. In fact, FIXED would be used in cases where  
  15. XMP and LISTING are used now. It is trivial to convert.  I so no great use for
  16. XMP and LISTING except for back-compatibility.
  17.  
  18.     WIDTH
  19.     
  20. I would like an attribute WIDTH=nn to specify the width of display.
  21. This can allow the viewer to select a font which will fit. It will also
  22. allow something 40 chars wide to be indented rather than having to 
  23.  
  24. start at the LH margin (and typically be filled out with tabs so that it
  25. doesn't look silly) like in a quoted command.  I would put an implementor's
  26. comment in that widths of 40, 80 and 132 are likely and handling those well
  27. would be a good move. Any oethr widths can be rounded up of course.
  28. In a style-oriented editor, that gives 3 styles: command, example,listing.
  29.  
  30.  
  31. >  the standard should
  32. >  include an end tag </PRE>.  We don't support an end tag, but should.
  33.  
  34. Definitely!
  35.  
  36. > I
  37. >  attampted to translate ms documents to html, with some success, but,
  38. >  equations (neqn) and tables (tbl), were close to impossible.  I'd like
  39. >  to use preformatted for those sections alone, and not the whole document
  40. >  (http://eies2.njit.edu/rakesh/paper.html).
  41.  
  42.     I get "Document address invalid or access not authorised" for
  43.     that one ... have you sepelt it right?
  44.  
  45.     NEW LINE
  46.  
  47. Whether lines are ended with newline or <p> is in fact a question of  
  48. practicality.
  49.  
  50. >  The idea of new lines being significant is only repungnant in the case
  51. >  of generating new hypertext.  The express purpose of <PRE> is to make
  52. >  use of externally formated text where new lines ARE significant.
  53.  
  54. Hold on. Let's get our ideas straight. We want FIXED to allow us
  55. to inlcude preformatted text.  We can never, however, just paste preformatted
  56. text into a <PRE> section because we will have to change the < and & characters
  57. to entities.  At the same time as we add those it's easy to add a <p> at the  
  58. end of every line.
  59.  
  60. It isn't just mail which has problems with newlines. There are horrible
  61. mainframe systems which have trouble with things which don't fit into card or  
  62. lineprinter images, and even VMS complains when a line buffer overflows. There  
  63. are probably a lot of finite line buffers in the world. When you imagine  
  64. (pathalogical case) putting an anchor on each of 80 characters, we can end up  
  65. with of the order of 1kB per line. When it totally resonable for you and me but  
  66. I bet someone will hate it.
  67.  
  68. But then of course we can always break lines before any tag closer > so it  
  69. doesn't matter anyway, right?
  70.  
  71. Dan's aygument remains that by SGML convention (only?) newlines are significant  
  72. only in "RCDATA" (replacable character data) in which one cannot have anchors.  
  73. If you need anchors, you need PCDATA (parsable CDATA) in which newlines are
  74. by convention not signifiant.
  75.  
  76. >  I used the <p> tags within <PRE> text in order to marginally support
  77. >  browsers that do not understand <PRE>.  I'll be glad to provide a
  78. >  version of manual pages without the <p>,  http://eies2.njit.edu:1234/man-p.
  79. >  The long term value of mixing <p> within <PRE> is dubious at best.
  80.  
  81. I absoltely agree that we don't mix <p> with significant newlines!
  82. My attempts to interpret your man pages lead to a lot of white
  83. space, as \n<p>\n was interpreted as 3 newlines!
  84.  
  85. Let's not bother marginally supporting any browsers. All the parser authors are  
  86. in this discussion, we can get it right and define it. We can then all
  87. retrofit it in time for the MIME text/html definition. OK?
  88.  
  89. I would like to see a /man/fixed with either <p> throughout or no <p>.
  90.  
  91.     <FIXED>
  92.     Every line ends with <p><p>
  93.     <p>
  94.     Blank or not<p>
  95.     </FIXED>
  96.  
  97.  
  98. >  The MidasWWW update for <PRE> looked nice and simple.  I look forward
  99. >  to trying it!
  100. >  
  101.  
  102. >  Let's get a <PRE> capability into the standard so we can put anchors  
  103. everywhere!
  104.  
  105. Absoltely.  We just need discussion or votes on 3 issues:
  106.  
  107.   Tag name:        <FIXED>        <PRE>        (other)
  108.  
  109.   Newlines:        \n        <p>
  110.  
  111.   WIDTH=nn        yes        no
  112.  
  113.  
  114. >  
  115.  
  116. >  jim
  117. >  
  118.  
  119.     Tim
  120.  
  121.